WORKSHOP ON NEXT GENERATION NETWORKS AND APPLICATIONS
(Athens, Greece, 8 May 2009)
Towards an open service environment in NGN
Marco Carugi ITU-T SG13 WP2 co-chair and Q.3/13 Rapporteur Senior Advisor, Nortel Networks, FRANCE marco.carugi@nortel.com
Athens, Greece, 8 May 2009
Outline
o NGN capabilities o NGN Open service environment - ITU-T SG13 o Collaboration with other SDOs and future items
Athens, Greece, 8 May 2009
2
Next Generation Services
o
From today’s networks
• Services are typically “vertically integrated”
• Services require specific infrastructure components for their delivery
o to NGN : flexible service creation and provisioning
• Horizontal Convergence: services are no more vertically integrated
• Network functions are componentised • New paradigm: standard “capabilities” as service enabling toolkit o Key objectives in NGN service standardisation
• Not just a new voice network • “Service level equal or better than in circuit-switched networks” • Services specified in terms of required “capabilities” • Service definitions not an objective like in legacy world
— Public Interest Services are a special case Service Shift as consequence of NGN service vs transport stratum separation
Athens, Greece, 8 May 2009 3
Application Network Interface in NGN Release 1 Reference Architecture (Y.2012)
Athens, Greece, 8 May 2009
4
The concept of “Capabilities” as re-usable building blocks for applications/services
Applications
Generic concept of ANI (Interface between Applications and Network)
Reusable blocks
Service environment
NGN resources
o A reusable set of Capabilities • Objective to reduce service development costs o Towards an Open NGN Service Environment for flexible
and agile service creation, execution and management
• (Open) Service platform concept • “Rapid change” is key for satisfying changing customer needs • New business opportunities
Athens, Greece, 8 May 2009
5
Capabilities for NGN Release 1 (Y.2201) and Release 2
o o o o o o o o o o o o o o o o
Transport connectivity Communication modes Multicast Media resource management Codecs Access Networks, network attachment User networks Interconnection, Interoperability and Interworking Numbering, naming, addressing Identific., authentic., authoriz. Security Routing QoS OAM and Survivability Accounting and Charging Management
Athens, Greece, 8 May 2009
o o o o o o o o o o o o o o o o
Mobility handling Service enablers Open service environment Profile management Policy management PSTN/ISDN emulation and simulation Public Interest Services support Critical infrastructure protection Non disclosure of info across NNI Inter-provider exchange of userrelated information Context awareness Identity management Content management IPTV services support capabilities Enterprise Networks support capabilities IPV6 support capabilities
6
Towards an open service environment in NGN (NGN OSE)
o “Open service environment” for flexible and agile service creation,
execution and management • Leveraging new capabilities enabled by technologies of different worlds (3G, but also Internet/Web 2.0 and IT) • Exposure of capabilities via standard application network interfaces • Portability and re-usability of capabilities across networks (and from Web to NGN or from NGN to Web) • Flexible development of applications and capabilities by NGN Providers as well as by Application Providers o Types of service creation environments recommended to be supported in NGN (Release 1): • IN-based service creation environment (INAP, CAMEL, WIN, …) • IMS-based service creation environment • Open service creation environment (OSA/Parlay, OMA, …)
Framework for value added applications leveraging network capabilities (COMMUNICATIONS-ENABLED APPLICATIONS) Athens, Greece, 8 May 2009
7
Service creation environments - example
Source: 3GPP IMS and OSA/Parlay
Athens, Greece, 8 May 2009 8
3rd party scenarios: Managed Delivery Services (MDS) – Y.2212
o NGN dynamic features and comprehensive service delivery control
capabilities are made available via MDS by the NGN Provider through ANI to 3rd Party Providers and their customers o 3rd Party Providers can offer enhanced services to their customers Example of MDS Business Model
Service Charge+
3 rd
Party Provider
3 rd Party Provider
QoS, Routing others Cost NGN Provider
Service Charge
MDS
Service Network Capability Connection Fee
Service+
User/ Customer
NGN Provider
User/ Customer
Network Capability+ Connection Fee
A win-win situation for both 3rd Party Provider and NGN Provider
Athens, Greece, 8 May 2009 9
Opening the NGN service environment through Telecom SOA and enhanced Web Services
o How to open
• Adopting a Service Oriented Architectures (SOA) framework from the IT world and enhance it as appropriate -> Telecom SOA • Using Web Services (WS) as implementation tool set of the Telecom SOA framework
— other tools (e.g. REST) are not excluded
o What to open (expose)
• Applications <-> Network capabilities (NGN)
Telecom APIs
• Network capabilities <-> Network capabilities
Target is an Open NGN Service (Delivery) Platform
Athens, Greece, 8 May 2009 10
An Open NGN Service Platform
End user created applications 3rd Party applications NGN Provider services
NGN common building blocks
Athens, Greece, 8 May 2009
11
Service Oriented Architectures (SOA)
o SOA framework was originally
developed in the IT world o SOA resources are made available to other participants in a network via independent services, accessed in a standardized way o SOA systems comprise loosely joined, highly interoperable services o SOA is attractive to businesses because: •Cross-platform •Highly reusable o Most SOA implementations identify Web Services as the means for realizing a SOA
o
Find Deploy
Bind
But new requirements for a Telecom SOA !
Athens, Greece, 8 May 2009 12
Enhanced Web Services for a Telco SOA
o
Applications
o o
Web Services
o o
We see a growing market success of middleware based on Web Services (e.g. eBay, Amazon and Google are major users of Web Services) Web Services are simple XML-based messages for machine-machine messaging, acting as XML-based APIs WS use standard Internet technologies to interact each other dynamically, open standards connect disparate platforms WS have well understood security model WS are loosely coupled, can be combined to form complex services
Converged Telecom Network (network capabilities)
o WS enhancements are needed to
support Telco SOA requirements
• •
Carrier Grade reliability and performance convergence of competing WS standards (SDO alignment and harmonisation)
13
Athens, Greece, 8 May 2009
Initial work items on SOA and WS topics in ITU-T SG13
• Y.2234 : Open service environment capabilities for NGN (Sept 2008)
— Y.OSE-arch (OSE functional architecture for NGN) launched in Jan 09
• Y.2212 : Requirements of Managed Delivery Services (Jan 08) • Y.2232 : NGN convergence service model and scenario using Web Services (Feb 08) • Y.2235 : Converged web-browsing service scenarios in NGN (Dec 08) • Docs based on previous work in OCAF Focus Group (Dec 06)
— Y.2901/Y.2902 - Carrier grade open environment model/components
Other ongoing ITU-T activities are SOA/WS related, including in
• ITU-T SG4 (NGN management - M.3060) • ITU-T SG17 (security aspects for SOA/WS) • ITU-T SG16 (middleware aspects for IPTV)
Athens, Greece, 8 May 2009 14
Service requirements for NGN OSE (1/2)
o The open service environment is required to
• provide standard APIs for application providers and developers, and potentially end users • provide service level interoperability underlying different networks, operating systems and programming languages • support service independence from NGN providers and manufacturers • support location, network and protocol transparency support OSE capabilities based on NGN providers’ capabilities [OSE capabilities based on application providers’ capabilities are not supported in this version] provide secure access to open service environment capabilities satisfying the general NGN security requirements provide capabilities for coordinating services among themselves and services with applications
Athens, Greece, 8 May 2009 15
Service requirements for NGN OSE (2/2)
o The open service environment is required to (con’t)
• provide the means to manage the registration of capabilities, services and applications • support service discovery capabilities to allow users and devices to discover applications, services and other network information and resources of their interest • provide service management capabilities • provide service composition capabilities to flexibly compose services and capabilities • offer an efficient development support environment which supports application construction, trialing, deployment, removal • allow interworking with service creation environments • support policy enforcement capability for resources protection and management, and service personalization
Athens, Greece, 8 May 2009 16
Service Composition example (implemented via Web Services tool set)
Parlay X API Call
Application::LocateAndCallUser
Choreography Description Language (CDL)
Web Service Description Language (WSDL)
WSDL
WSDL
WSDL
WSDL
Location Capability
Presence Capability
Session Handling Capability
Charging Capability
Athens, Greece, 8 May 2009
17
NGN OSE functional positioning
Athens, Greece, 8 May 2009
18
Functional components of the NGN OSE functional group
Athens, Greece, 8 May 2009
19
[ITU-T Y.2012] ASF&SSF FEs
Mapping of NGN OSE functional components into NGN ASF&SSF Functional Entities
APL-GW-FE
APL-SCM-FE
AS-FE
SS-FE
New FE currently not identif ied
[Y.2234]
Service discovery Service management Service registration Service coordination O S E Service composition Service development support Interworking with service creation environments
serves as an interworking entity between the applications, and services and capabilities of the NGN (adapted from [ITU-T Y.2012]) optional optional optional not applicable not applicable
manages interactions between multiple application services (or servers) [ITU-T Y.2012]
supports generic application server functions including hosting and executing services [ITU-T Y.2012] not applicable not applicable not applicable not applicable not applicable
provides access and interworking to a legacy IN SCP [ITU-T Y.2012]
not applicable not applicable not applicable optional optional
not applicable not applicable not applicable not applicable not applicable
optional optional optional optional optional
optional
not applicable
not applicable
not applicable
optional
optional
not applicable
optional
optional
optional
Policy enforcement Athens, Greece, 8 May 2009
optional
optional
not applicable
not applicable
optional
20
Relationship of ITU-T SG13 with other SDOs: collaboration has started o NGN OSE capabilities • Require the use of standard interfaces • Open the NGN capabilities to third parties • Provide a SOA enabled environment • Web Services as an implementation technology for NGN OSE o Many developments in other SDOs are or may be relevant for ITU-T objectives • OMA (OMA Service (Provider) Environment, enablers) • Parlay Group (Parlay-X Web Services/API work now in OMA) • TeleManagement Forum (Service Delivery Framework) • OASIS (Telecom Member Section activity, SOA Ref. Model, other) • other SDOs (W3C, IEEE NGSON, OGF, OMG etc.) o Collaboration started with other SDOs • Initial joint meetings, liaisons, analysis of other SDOs’ documents • Collaboration needs to continue and increase in intensity
Athens, Greece, 8 May 2009 21
Analysing the work of other SDOs for NGN OSE – the OMA Service Environment example
Applications
I0+P
Applications
I0+P
Service Provider or Term inal Dom ain
Policy Enforcer
Execution Environment (Software Life C ycle M gm t, Load balancing, caching, O& M , etc.)
I0
Web service bindings W eb Other bin dings … … Enabler im plem entation Enabler im plem entation Enabler im plem entation Enabler im plem entation
I1
I2
To Resources in Operators, term inals, Service Pro viders
Source: Open Mobile Alliance
Athens, Greece, 8 May 2009
22
Parlay-X Web Services/API specifications
Parlay-X Web Services specifications provide simple, abstracted telecom Web Services based on use of network functionality, features and enablers
o o o o o o o o o o o
Part 1: Part 2: Part 3: Part 4: Part 5: Part 6: Part 7: Part 8: Part 9: Part 10: Part 11:
"Common" "Third party call" "Call Notification" "Short Messaging" "Multimedia Messaging" "Payment" "Account management" "Terminal Status" "Terminal location" "Call handling" "Audio call"
o o o o o o o o o o o
Part 12: Part 13: Part 14: Part 15: Part 16: Part 17: Part 18: Part 19: Part 20: Part 21: Part 22:
"Multimedia conference" "Address list management" "Presence" "Message Broadcast" "Geocoding" "Application driven QoS" "Device Capabilities and Config" "Multimedia streaming control" "Multimedia multicast session management" "Content management" "Policy"
P a r la y -X A r c h ite c tu r e
P a rla y -X A p p lic a tio n s P a rla y A p p lic a tio n s P a rla y -X W e b S e rv ic e s P a rla y A P I P a rla y G a te w a y N e tw o rk P ro to c o ls N e tw o rk E le m e n ts P a rla y -X A P I
Athens, Greece, 8 May 2009
23
TMF SDF: positioning and relationship with OSS/BSS
Internet / 3rd Parties / Enterprises
Service Layer
Application suites Application Servers
SDP
SDF
Control Layer
SC E
SS7
SIP / IMS
IMS
OSS/BSS Platforms
Access Transpor t Layer Layer
IP / MPLS / PBT SONET / SDH / WDM
Wireline: DSL, Cable, FTTx, PSTN
Wireless: 2G, 3G WiFi, WIMAX
Source: TeleManagement Forum
Athens, Greece, 8 May 2009
Device / Client Layer
24
o
o o o o o
Future SOA/WS topics within ITU-T SG13: an informal and non-exhaustive list (*) Requirements of service interfaces between Applications and NGN capabilities (Telecom APIs for carriers and enterprises) • Key APIs • Building on relevant business cases (IPTV, USN, etc.) SOA framework for NGN (carrier-grade, service traceability etc.) Standard requirements and SOA/WS enabled capabilities of service delivery platforms for NGN SOA/WS enabled NGN (2.0) functional architecture and related service components (IMS, others) Middleware aspects • Application-specific middleware requirements versus NGN OSE Application scenarios • SOA based service composition and NGN OSE • 3rd party provider applications • Composition of NGN capabilities and Web 2.0/Internet capabilities • Composition of NGN services and legacy services
25
(*) SG13 is currently developing its work plan in this area
Athens, Greece, 8 May 2009
Conclusion
o Towards an open service environment in NGN
• Service Oriented Architectures (SOA) as framework • Web Services (WS) as implementation tool set o SOA and WS will enable new business revenues within the integrated IT+C environment • but bring new challenges to standards development (not fully discussed here) o ITU-T has started work in this direction • NGN OSE and other developments o Various other SDOs, Forums, and Consortia are involved in this space • standards convergence and harmonization are essential • ITU-T collaboration with other SDOs has started to integrate relevant specifications with the NGN standardization framework
Athens, Greece, 8 May 2009 26
Thank you for your attention Questions ?
Athens, Greece, 8 May 2009
27
Backup slides
Athens, Greece, 8 May 2009
28
OSE functional requirements (1/4)
o Service Coordination is required to
• Provide coordination of applications and services with capabilities • Provide the tracking of NGN capabilities or service components from various application providers, and the relationship between these capabilities or service components • Support the information on state change of capabilities or service components for applications and services o Service Discovery is required to • Provide service discovery for physically distributed NGN services • Support a variety of discovering criteria • Use user and device profile information for discovering proper service • Allow users to discover user-interest services, device-interest services and network information
Athens, Greece, 8 May 2009 29
OSE functional requirements (2/4)
o Service Registration is required to
• Provide service registration, including configuration, activation, publication and service deregistration • Provide a variety of service registration features (e.g. manual, autonomous) for NGN services • Support a variety of registration parameters, including mandatory and optional parameters o Service Management requirements include • Provide monitoring function of registered services for availability, predicted response time • Provide managing function of QoS information about registered NGN services • Provide version management function to NGN services for interoperability • Provide notification service functions for updated services • Provide failure detection and recovering functions for unexpected failures
Athens, Greece, 8 May 2009 30
OSE functional requirements (3/4)
o Service Composition is required to
• Provide composition language that describes interaction flow among NGN services • Support the composition of NGN services statically or dynamically o Service Development Support is required to • Support services re-use and allow for services interchangeability • Support mixing-and-matching of services by management of interfaces and consistent semantics of shared data/schema across these services • Support the full life cycle of components, including installation, configuration, administration, publishing, versioning, maintenance and removal • Support delivery-agnostic application design to allow applications to be implemented without requiring re-design for each development scenario • Support tracking of dependencies among services
Athens, Greece, 8 May 2009
31
OSE functional requirements (4/4)
o Interworking with Service Creation Environments is required to
• Support open service creation environment • Support IP multimedia subsystem (IMS)-based service creation environment • Support Intelligent network (IN)-based service creation environment o Policy Enforcement is required to • Provide a description language to express various kinds of policy rules • Provide a policy execution framework to interpret and execute the policies • Protect services from unauthorized users’ requests and manage requests based on the policy rules
Athens, Greece, 8 May 2009
32
Y.2234 Appendix: relevant developments in other SDOs [1/5]
NGN capabilities OSA/Parlay OMA OASIS W3C OMG
Current effort: - UPMS (SOA extension of UML) - BPDM Existing Standards: - UML - EDOC: component architecture - Distributed Object Computing
TMF
TMF053 series: NGOSS Technology Neutral Architecture (TNA) GB921 series: eTOM, business process framework GB922 series: SID, shared information architecture NGOSS Contract Metamodel (Work In Progress)
Service Coordination
PEEM (Policy Evaluation, Enforcement and Management), OSPE (OMA Service Provider Environment)
Web Services Policy – Framework WS-Coordination WS-Business Activity WS-Atomic Transaction Web Services Policy – Attachment Web Services Policy Namespace Web Services Policy XML Schema
Current effort: Universal Description, Discovery and Integration (UDDI) Service Discovery Discovery of framework and network service capability features OWSER (UDDI), OMA’s DPE, OMA’s GPM ebXML Registry Information Model (RIM) ebXML Registry Services and Protocols (RS) Web Services Description Language (WSDL) - UPMS (SOA extension of UML) - BPDM Existing Standards: - RAS : Reusable Asset Specifications - RAS Description: Metamodel for describing and managing reusable assets
Athens, Greece, 8 May 2009
33
Y.2234 Appendix: relevant developments in other SDOs [2/5]
NGN capabilities
OSA/Parlay
OMA
OASIS
W3C
OMG
TMF
Service Delivery Framework (Work In Progress)
Service Management
Registering of network service capability features, Integrity Management
Management Using Web Services (WSDM-MUWS) Management Of Web Services (WSDMMOWS) WS-Notification WS-Brokered Notification
OSPE (OMA Service Provider Environment)
a framework that supports and integrates all functions required for the lifecycle of a service delivered to Customer, Description: looking across all stakeholders in a at runtime system, Service Provider environment. Service Modeling monitoring and SDF unifies under a logical Language measuring its and view service design, evaluating these creation/composition, WS-Eventing measurements against deployment, activation, what the expectations provisioning, sale and campaign management, RAS: to publish the execution, operations, services charging, billing and revenue management, retirement, monitoring and trouble resolution etc. BPRI: Business Process Run time Interface UPMS,
Service Composition
PEEM((Policy Evaluation, Enforcement and Management)
Business Process Execution Language for Web Services
Web Services Choreography Description Language
BPMN, BPDM
Athens, Greece, 8 May 2009
34
Y.2234 Appendix: relevant developments in other SDOs [3/5]
NGN capabilities OSA/Parlay OMA OASIS W3C OMG TMF
TMF053 series: NGOSS Technology Neutral Architecture (TNA) - UPMS, - BPMN, Service Development Support XDM, OSPE (OMA Service Provider Environment) Service Modeling Language - BPDM Existing Standards - EDOC GB921 series: eTOM, business process framework GB922 series: SID, shared information architecture GB942 Contract Guidelines and Principles NGOSS Contract Metamodel MTNM/MTOSI, OSS/J (TIP)
ebXML Registry Information Model (RIM) Service Registration OSPE (OMA Service Provider Environment) ebXML Registry Services and Protocols (RS) Universal Description, Discovery and Integration (UDDI)
Existing Standards - RAS - MOF
Athens, Greece, 8 May 2009
35
Y.2234 Appendix: relevant developments in other SDOs [4/5]
NGN capabilities
Interworking with Service Creation Environments Web Services Policy Framework Service PEEM((Pol Component Web Services Policy icy Architecture Namespace Evaluation, (SCA) Policy Enforceme Framework Web Services Policy nt and XML Schema Privacy Manageme policy profile Web Services Policy nt) Primer of XACML Web Services Policy Guidelines for Policy Assertion Authors Web Services Policy Attachment
OSA/Parlay
OMA
OASIS
W3C
OMG
TMF
Policy Enforcement
Policy Management SCF
SID Policy Framework
Athens, Greece, 8 May 2009
36
Y.2234 Appendix: relevant developments in other SDOs [5/5]
NGN capabilities
OSA/Parlay
OMA
OASIS WS-Security WS-Security: SOAP Message Security WS-Security: Username Token Profile WS-Security: SAML Token Profile WS-Security: X.509 Certificate Token Profile WS-Federation
W3C
OMG
TMF
Security
SEC_CF Authentication, (Security Authorization Common Function )
Athens, Greece, 8 May 2009
37